Field of Invention
The present invention relates generally to data communications and more specifically it relates to the secure delivery of sensitive data in a software defined network (SDN) while passing through network regions that potentially carry security risks.
Discussion of Related Art
Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field.
In a computer network data packets sent toward a destination are relayed between switches, some of which may have been compromised. As a result, a need arises for secure communications over insecure network regions. An efficient way to send data with the desired privacy is encryption between the source and destination. As long as the encryption key is kept safe, the data will be safe. However, solely encrypting the content of the data does not guarantee absolute privacy since the attacker can infer communicating end points' identity, and learn about the frequency and volume of the communications. In such a case, it is imperative to encrypt not only the data content but also the source and destination IP addresses. The entire IP packet (including the IP header) can be encrypted close to the source, and sent to another trustworthy encryptor close to the destination, where it can be decrypted, and delivered safely to the destination. Doing so, data packets travel through insecure network regions in a completely private manner. However, performing all these tasks in real-time and executing without manual intervention is not possible in the current Internet.
Today's Virtual Private Networks (VPNs) [see paper RFC 2661, Layer Two Tunneling Protocol ‘L2TP’.] use the above-mentioned logic to provide private communications on the global Internet. Using the VPN technology, a company can interconnect its sites at different locations over an insecure Internet infrastructure. To do so, all packets in a site are sent through a secure ‘middle-box’ at the edge of the network, which is essentially a firewall where the source and destination addresses are checked. The eligible packets are encrypted and then forwarded to the firewall of the destination site in a tunnel (just like a private line). In turn, the firewall at the destination site decrypts the incoming packets, recovers the original receiver address and delivers them to their right host. IPSec (see paper RFC 4301, Security Architecture for IPSec) is the most known and used prior art technique to encrypt packets.
In a VPN, source and destination addresses are manually configured before any communications start. Furthermore, usually all communications between a sender and receiver are treated exactly the same manner regardless of whether they carry any sensitive data or not, and the routed path between the VPN boxes is fixed.
A variant of VPN is a Multi-protocol Label Switching (MPLS) based VPN [see paper RFC 3031, MPLS Architecture], which has gained wide popularity to establish secure tunnels within multi-protocol networks. MPLS allows packets to be forwarded at layer-2 (the switching layer) rather than having to be passed up to layer-3 (the routing layer). It avoids time-consuming next hop address table lookup by forwarding based on a simple tag inserted between layer-2 and -3 packet headers.
In MPLS, each packet gets labeled on the entry point into the network at a label edge router (LER). All subsequent routers perform packet forwarding based only on the label—they never look as far as layer-3 header information. Finally, the egress LER removes the label and forwards the original packet toward its final destination. MPLS VPNs are statically established. MPLS routers distribute tags using Label Distribution Protocol (LDP), which is rather complex.
SDN [see ONF white paper entitled, “Software Defined Networking: The New Norm for Networks,” Apr. 13, 2012, 12 pgs.] is a new approach for networking that allows decoupling of control and data planes. In summary, decisions about traffic routing are performed at the control plane, while traffic forwarding is performed at the data plane according to the rules determined by the control plane. An SDN controller is the software where control plane decisions such as routing are made. It may reside in a single computer or may be distributed to many computers. There may be one or more controllers per SDN. The controllers of the same or different SDNs exchange control information about their respective networks (just like BGP does). SDN applications are written in Or on the controller, which enable different ways of management of data plane routes based on specific operator service application needs such as the one in this invention.
The controller is a logically centralized entity in charge of (i) translating the requirements from an SDN application down to the data path in the form of ‘forwarding instructions’; and (ii) providing an SDN application a view of the network (which may include complete or partial view of network topology, statistics and events). The controller is mainly comprised of a ‘control logic’, a ‘control to data plane interface’ to control the data plane, and an ‘API’ for applications to interact with the controller, and a ‘controller to controller interface’ to allow interaction across controllers.
The SDN data plane is where forwarding and packet processing are performed. However, no routing function is executed within the data plane. A data plane entity is a ‘switch’ (or forwarder), which contains one or more fast traffic forwarding engines. Each switch has an interface towards the SDN controller to receive forwarding instructions and to send measurements collected on the switch.
The SDN control to data plane is an interface [see paper to McKeown et al., entitled, “OpenFlow: Enabling innovation in Campus Networks,” ACM Communications Review] that provides at least (i) a programmatic control of all forwarding operations; (ii) capabilities advertisement; (iii) statistics and event reporting. One such interface is OpenFlow [see OpenFlow Switch, Specification Version 1.5.1], defined by the Open Networking Foundation, ONF, which is often misunderstood to be equivalent to SDN, but other mechanisms/protocols could also fit into the concept. Therefore, this patent application is not reliant on the OpenFlow protocol or its current capabilities.
SDN security has recently gained significant momentum especially in the standards bodies [see paper Network Working Group, entitled, “Requirements for Security Services based on Software-Defined Networking draft-jeong-i2nsf-sdn-security-services-01]. However, solutions to many SDN security issues have not been figured out and implemented.
When MPLS is supported within an SDN, the controller decides on which tags to use along an LSP and distributes instructions to the forwarders along that LSP. Meaning, there is really no need to run a Label Distribution Protocol (LDP) within a single SDN. When there are several SDNs, however, along the LSP, then the controllers involved along the LSP have to collaborate to agree on labels. However, that collaboration does not have to be as complex as LDP designed for a highly distributed routing function of the current Internet. While LDP has to scale in the order of routers (e.g., thousands), SDN-MPLS tag distribution has to scale in the order of controllers (e.g., tens).
Embodiments of the present invention are an improvement over prior art systems and methods.